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(57) Abstract 

A server routes one's incoming messages to his/her communication devices according to his/her routing preferences, and modifies 
the messages as needed. For example, the server can route an incoming page to one's email account and, if necessary, modify the page 
so that it is compatible with the email client. Thus, the server enables a number of diverse features such as: selection of routing topology 
(direct or indirect), translation of network restrictions, conditioning a synchronous communication for reception by an asynchronous device, 
message encryption, and callback or "buddy list" services. 
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IMPROVED SERVER AND METHOD FOR ROUTING MESSAGES TO ACHIEVE 

UNIFIED COMMUNICATIONS 

Technical Field: 

5 The invention relates generally to communication networks that include 

computer hardware and software, and more particularly to a server, software run by 
the server, and a method implemented by the software for routing messages 
according to the message recipient's preferences. 

1 0 Background of the Invention: 

Today, a person may have more than one personal message device such as 
a wireless pager (e.g. a Skytel pager) or an e-mail client (e.g. Microsoft Outlook) that 
provides access to the person's e-mail account. Often, these devices communicate 
to other message devices via a computer network such as a local intranet or the 

15 Internet. 

Figure 1 is a block diagram of a conventional computer network 10, which 
allows communication between message devices. The network 10 includes a 
sender's computer 12s t which has an input device 13s (e.g. a keyboard or a mouse) 
coupled thereto and which includes a processor 14s coupled to a storage device 

20 16s. The network 10 also includes a recipient's computer 12r, which has an input 
device 13r and which includes a processor 14r and a storage device 16r. For 
example, the storage devices 16s and 16r may include a hard drive, volatile 
electronic memory, or both. The computers 12s and 12r are connected to a 
communication path 18 by networking circuitry that is omitted for clarity. For 

25 example, the path 1 8 may represent the communication lines that tie into and form 
the Internet. The processor 14s can run messaging devices such as a desktop 
pager 20s, a web browser 22s (e.g. Netscape Navigator), and an e-mail client 24s, 
which allows the sender to send and receive e-mail messages via an e-mail server 
26s. Although the processor 14s executes the software that runs these devices, it is 

30 common to state that the computer 12s runs these devices. The sender may also 
have a wireless pager 28s and a voicemail server 30s, which are also connected to 
the path 18. The voicemail server 30s may allow the sender to send and receive 
voice messages via the computer 12s or via a telephone system (not shown). 
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?**• *" reCiPien, ' S COmpu,er 12r ™ - ^ktop pager 20, a web browse, 
22r, and an e-mai, client 24r, which allows the recipient to view e-mai, received on an 
e-ma,l server 26r. Also. the recipient may have a wireless pager 28r and a voicemail 
server 30, AHhough the compute,* and message devices are labe,ed as sending 
5 recennng dev,ces for descnp«on purposes. « is understood tha, these labels are 
artery such that the sending computer and message devices can be used to 
receive messages and the receiving computer and message devices can be used to 
send messages. 

10 oath J h 7tT 10 ^ alS ° ' nC,Ude 3 fl ' e Se,Ver 32 ' WhiCh is «»»"« »° the 
10 18 and wh,ch can assist wKh the transfer of messages ^ ^ ^ 

messaging dev,ces and the recipient's messaging devices. For exampie. the server 

I n 3 IT ^ inteme ' (,SP) ' Whloh fe <*«~ *• <™sfer 

of messages be^een ISP account holders and between an account holder and a 

15 ZT° ^ ^ S6,Ver M ^ 66 3 Pa9i " 9 — <Ha. 

transfers messages between the wireless pagers 28s and 28r 

in operation, me nehvork 10 typically allows too topologies for transferring 

messages from one device to anotoen me point-to-point (PTP) topology, and 

o^y vWh me PTP topology, a message is routed directly between fte J i f 

20 sel ^ eXamP ' e ' USln9 3 ,OPOl °^ *» — *P «« 20s 

20 nd a message diredy to the desktop pager 20r via me computer 12s. me path 

1* and the computer 12r. ,n some applications, such as where it an ISP server 
the server 32 may open this direct path between the pagers 20s and 20r 
Convey, with a stertopoiogy, me message is routed through an intermediate 

25 28 , ^ 35 "" V " 32 F ° r ™* us '"9 * - «oPology me pager 
25 8 sends a message Weeded for the pager 28r to the server 32, which mey b m 

0 r P ~ ys T r er - ne se ™ 32 * en pro — ,he - « 

he P-£T 8 ^ OCCUr f ° r SBCUrt,y ° r ° ,her reas °"* Therefore, because 

me PTP topology eiiminates the overhead of having the setver tecefce and send Z 

30 :;rr raotenfts ^^ 

Unfortunately, if me environment of the network 10 does not allow a.l 
messages to be sen, wKh a PTP topotegy, men me server 32 may be programmed 
te toute a„ messages with a star topology te prevent messaging failure Z ^ 



WO 00/41533 



PCT/US00/00688 



create an unnecessary bottleneck at the server 32, thus significantly increasing 
access times and aggravation for users of the server 32. Alternatively, if the same 
type of server 32 is to be installed in a network 1 0 having an environment that does 
allow all messages to be sent with a PTP topology, then the server software will 
5 have to be modified to allow this. Thus, if the server 32 can be used in both network 
environments, then the server manufacturer will have to develop and offer two 
respective software packages, one for PTP and another for star. Furthermore, the 
customer will have to install new software if the network environment changes, or if 
he wishes to install the server 32 in another network 10 having a different 
10 environment. 

Furthermore, a recipient is often unable to retrieve messages from some of 
his message devices for extended periods of time, and if a message device is 
unavailable to receive a message, the message may be lost. For example, suppose 
the sender sends an e-mail message from his e-mail client 24s to the recipient's e- 

1 5 mail server 26r. If the recipient is out of town and has no access to the server 26r 
other than through the e-mail client 24r, then he must wait until he returns before he 
learns of and can read the sender's e-mail message. Alternatively, if the sender 
sends a desktop page from his pager 20s and the recipient's desktop pager 20r is 
not running, then the message has nowhere to go and may be lost. 

20 Additionally, a message transfer may be unsuccessful if the sending device is 

of a different type than the receiving device. For example, if the recipient's e-mail 
client 24r is Microsoft Outlook, it may be unable to read an e-mail message from e- 
mail clients other than those sold by Microsoft. 

Moreover, in applications where the server 32 is common to the sending and 

25 receiving devices, such as when it is an ISP server, the server 32 may use polling to 
allow a sender to determine if an intended recipient's message device is available to 
receive a message. For example, if the sender wants to send a desktop page, he 
may first want to determine if the intended recipient's computer is logged onto the 
server 32, and thus if the recipient is "online" and able to receive the page. To make 

30 this determination, the sender requests, via his computer 12s, the server 32 to poll 
all of the computers that are logged onto the server 32 and to notify the sender if one 
of these computer's is the recipient's computer 12r. Unfortunately, because the 
server 32 must communicate with each logged on computer, such polling requires a 
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significant amount of processing time, and thus can significant* increase user 
access >mes particular* during hours of peak use F 

leit r for *" number of ,o99ed -° n °~- - ««- « »•»' 

Furthermore, rf the computer 12r is not logged onto the server 32 at the time th a , » 

12 subsequent* togs on is to subseguentty regues. the server 32 to repeat! 
pollmg Thus, mis significantly burdens «he sender, because he may have ro mgues, 
severs, po„s befote he either gives up or the computer 12r togs onto 

° SUMMARY OF THE INVENTION 

in one aspect of the invention, a server is provided for facilitating 
communion between a sending device and a receiving device. The server 
includes a storage device for storing a program, and a processor for execuZ me 

: d7r to rr n9flrs,andsecondstetes - r 9 

dev,ce to send a message past the processor to the receiving device if the „ m 
andsends the message to the receiving device if the processor is in the second 

routinn?" 8 ; 3 ^ aU ' 0ma,ical1 ' sete « *«* implement the best network 
roubng topoiogy, star or PTP, on a message-by-message basis. ,n one 
embodiment, me server selects and implements the PTP topology unless i, cannot 
*e lamented, in which case „ server seiects and implements 2 ZZ- 

BRIEF DESCRIPTION OF THE DRAWINGS 

prior art ' " " " * C °"™°- scooping to the 

servers^ 7 " " V°" " « * P—*™ that me routing 

topology for transmission of a message. 
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Figure 5 is a computer screen generated by an embodiment of the message 
routing clients of Figures 2 and 3 for showing a message sender the available 
message devices of an intended message recipient. 

Figure 6 is a web home page generated by an embodiment of the message 
5 routing server of Figures 2 and 3 for showing the available message devices of an 
account holder. 

Figure 7 is a web page generated by an embodiment of the routing servers of 

Figures 2 and 3 for prompting a sender who is not logged onto the server for a 

message and other related information. 
10 Figure 8 is a web page generated by an embodiment of the routing servers of 

Figures 2 and 3 for prompting a sender who is logged onto the server for a message 

and other related information. 

Figure 9 is a flow chart of a message routing procedure that an embodiment 

of the routing servers and clients of Figures 2 and 3 implement. 
15 Figure 10 is a computer screen generated by an embodiment of the routing 

clients of Figures 2 and 3 for prompting a recipient for his off-line routing 

preferences. 

Figure 1 1 is a computer screen generated by an embodiment of the routing 
clients of Figures 2 and 3 for prompting a recipient for his on-line-but-unavailable 
20 routing preferences. 

Figure 12 is a flow chart of a procedure implemented by an embodiment of 
the routing clients of Figures 2 and 3 for finding all of the message devices installed 
on the computers that respectively run the routing clients. 

Figure 13 is a device-listing screen generated by the embodiment of the 
25 routing clients that implement the procedure of Figure 12. 

Figure 14 is flow chart of a call-back procedure implemented by an 
embodiment of the servers and clients of Figures 2 and 3. 

Figure 15 is a call-back-notification screen generated by the embodiment of 
the routing clients that implement the client portion of the call-back procedure of 
30 Figure 14. 

Figure 16 is a flow chart of procedure implemented by an embodiment of the 
routing clients of Figures 2 and 3 for learning a recipients messaging patterns and 
generating a routing preference based on these patterns. 
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^"'"^'^Seneratedbytheembodimentofthe^ng 
clients that implement the procedure of Figure 16. 

•he ae r 9Ure "r ^ Chart ° f 3 PrOCedUre in *> te ™»««« ^ one embodiment o, 

clients of the same user are logged onto the server 

Figure 19 is a flow ohart of a procedure implemented by one embodiment of 
ft. servers or Ciems of Figures 2 and 3 for sefting oljent pnoritv based on ™ 
•My # mu.tip te clients of *e same user are logged on to flTserve, 

' DETAILED DESCRIPTION OF THE INVENTION 

accord!^, 2 " * T °' " emb ° dimen * °' 3 ~-a,ion network 40 

accordmg to the mvention. where elements that are common to Figure 1 have the 

same referenc ra |, The network 40 includes a routing serl 42, wlh 

mcludes a conventional prooessor 44 and a convenliona, storage device 46 In one 
embod,ment, the device 46 includes a volatife memo* such as dynamic randl 
access memory (ORAM), a non-volaflie memory such as a hard disk or a 
combination of both volatile and nonvolatile memory. The processor'^ of Ihe 

r"oT,h" rou,in9 which ' as discussed bel °- «— <* - 

server 42 ,o route ,he recipes messages according to the recipient message 
«*g preferences. The processor 14s ofthe sendees computer 12s may also run 
- muting o„en. 48s. which in one embodimen, is flte same as ,he routing i^sT 
in one em bodimen,, the server 42 runs My Agent server software from C v^e 
Co^o ra bon,and m ec,ien te 48sand48rare M yAgen,softwarec, fe n tefr o m Ac,ivr 

wfth Fig'ulTlTth! Fi9Ure , 2, 38 diS ° USSed h deta " in ~*«~" 
w* F,gures 4-19, the genera, operaflon ofthe network 40 is discussed according to 
one embodiment of the invention. ccoraing to 

In operation, the server 42 routes the recipient's incoming messages to the 

ZTorr device specifed ty ,ha recipienrs ^ ~r r 

I'eT * PreferenCeS ^ ,ha * 42 route a » —age, 

directed to the desktop pager 20r to the e-mail server 26r 

To allow the server 42 to perform such rerouting, the recipient gives the 
sender access to one or more of the recipient, message devices via I se^er 42. 
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In one embodiment, this access is through the sender's routing client 48s, the 
recipient's web page set up on the server 42, or the recipient's address with respect 
to the server 42. 

The server 42 automatically determines the best network topology for routing 
5 a message from the sending device to the receiving device specified by the 

recipient's routing rules based on criteria including the sender's identity, the identity 
of the recipient's message device to which the sender has directed the message, the 
priority of the message (e.g., urgent, normal, or low), the receiver's availability, and 
the size of the message. In one embodiment, the server 42 routes the message 
10 using a PTP topology unless this topology is unavailable with respect to the 
message. 

In one embodiment, if the format, such as the protocol, size, or encryption, of 
the sent message is incompatible with the receiving device specified by the 
recipient's routing preferences, then the server 42 reformats the message before 
15 sending it to the receiving device. Thus, the server 42 allows one type of message 
device, such as the web browser 22s, to send a message to another type of 
message device, such as a desktop pager 20r. 

In another embodiment, the server 42 eliminates the problems with 
conventional polling by maintaining a list of the users that are currently logged onto 
20 the server 42. This allows a user to request a "callback" from the server 42 when 
another user logs onto the server 42. 

In yet another embodiment, the client 48r monitors the recipient's patterns 
with respect to his received messages, and based on these patterns, automatically 
suggests, develops, or maintains the routing preferences that best fit the recipient's 
25 lifestyle. 

In still another embodiment, the server 42 allows a user to have multiple 
computers 12r simultaneously logged onto the server 42, where each computer 12r 
is running a respective routing client 48r For example, it is common for a user to 
have a work computer and a home computer. Thus, the server 42 allows both of 
30 these computers to be simultaneously logged on and running respective routing 

clients 48r. To prevent conflicts if the clients 48r have different routing preferences, 
the clients 48r determine which of them is the primary client whose routing rules the 
server 42 will follow. 
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a „, V" 3 blOCk dia 9 ram communications network 60 according ,o 

anothe embedment of me invention, where .ike events have «ke referee 
numen* w«h respect «o Figures 1 an, 2. ,n ,he network 60, the com^TL 

by .he dashed lines 63s anTsT COnVen,i0na ' 

the computer 1 2s and the server fu e , . Resents the Internet, 

,IU ine server 64s commun cate with earh nth^r „ 
and the comDuter 1 ?r tner over an intranet, 

- ^ , where the servers 64s and 6^ ^ " 
Frgure 2. Thus, in this embodiment, the server 64s routes „*,« 7 

St,H referring to Figure 3. despite the firewalls 63s and 63r the server 42 

rvpica,,, .e ^z^z::r:: 2 r recip,eMs r ° u,in9 - 

topology for such a message Bu, LZt ZZ Z ' mp '~9 « "TP 
- Proper topoiogy, the same ter^Z^ZZZ ~ "* m " ta * —* 
oan also be used in the network 60 rTatt el r 40 °' 2 

2 end 3. respectively For c Jh! !, * "^"^ 40 and 60 of Fi 9 ure * 

unless othele Z£ ^ " ** ^ *° "» — °< F ^ * 
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60 of Figure 3, however, the pager 20s typically sends this information to the path 18 
via the server 64s. The message-initiation header typically includes information such 
as the identities of the sender and recipient and the length and priority of the 
message. Furthermore, in one embodiment, the server 42 determines the identities 
of the sending and intended receiving devices from the format of the message 
header. For example, a header from the desktop pager 20s often has a different 
number of bytes or is otherwise different than a header from the web browser 22s. 

Next, referring to steps 72 and 73, the server 42 examines the message- 
initiation header and, based on the header, the network environment, and the 
recipient's routing rules, determines the appropriate receiving device and whether or 
not PTP communication between the sending and receiving devices is possible. 

For example, suppose the sender desires to send a message from his 
desktop pager 20s to the recipient's desktop pager 20r. Furthermore, suppose that 
the recipient's routing rules indicate that the desktop pager 20r is to receive this 
message. If the server 42 determines that there are no firewalls or other network 
environment conditions that prevent a PTP topology, it implements a PTP topology. 

Alternatively, suppose the sender desires to send a message from his e-mail 
client 24s to the recipient's e-mail account on the e-mail server 26r, and that the 
recipient's routing rules instruct the server 42 to route all messages directed to the e- 
mail server 26r to the desktop pager 20r. If the format of the message from the e- 
mail client 24s in incompatible with the desktop pager 20r, then the server 42 
determines that a star topology is appropriate so that the server 42 can receive and 
reformat the message from the e-mail client 24s and then send the reformatted 
message to the desktop pager 20r. For example, desktop pagers such as the 
desktop pager 20r often limit the size of a received message to 100 - 200 bytes. 
Therefore, if the message from the e-mail client 24s is longer than this, the server 42 
will decide on a star topology so that it can receive and truncate the message before 
sending it to the desktop pager 20r. 

Or, if the message is so large or has so many recipients that a PTP topology 
would be unable to efficiently handle the message, the server 42 may implement the 
star topology. For example, suppose the sender wishes to send an e-mail message 
having a one-megabyte attachment to ten recipients, and that all of the recipients' 
routing rules indicate that the server 42 is to route such an e-mail message to their 
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respective e-mail servers 26r. In one embodiment, beoause of the file length and the 
relatrvely large number of recipients, the server 42 determines that multicasting is 
more efficient than setting up direct FTP paths between the sender's e-mail server 
26* and the respective e-mail servers 26r. Therefore, the server 42 implements a 
star topology by instrucfing the e-mai, server 26s to send the message to the server 
42 only once, and then sending toe received message to each oftoe e-mai, servers 
26r of toe respective recipients. Alternatively, the server 42 may forward the 
message to a conventional multicasting server (not shown), which sends the 
message to each of the e-mail sen/era 26r. 
• Moreover, the server 42 may allow the sending device, such as toe desktop 

pager 20s, to firs, *y to send a message with a PTP topology, and if this attempt 
farls, the server 42 instructs the sending device to retry with a star topology 

Referring to Figure 3, the server 42 may implement variations of toe star 
topology in toe network 60 if one or both of the firewalls 63s and 63r prevent the 
server 42 from opening a PTP path between a message device of the network 62s 
and . message device of the network 62r. In one embodiment, after determining 
that rt cannot implement a PTP topology, toe server 42 first tries to implement a 
version of the star topology in which the server 42 bypasses the servers 64s and 64r 
and communicates directly with the sending and receiving devices This is 
srgnmcantly faster and causes less traffic on the networks 62s and 62r than if toe 
message .were routed through the servers 64s and 64r. For example, iftoe desktop 
pagers 20s and 20r are toe sending and receiving devices respectively, then the 
server 42 receives the message from the pager 20s and sends It to the pager 20r in 
a manner similar to mat described above with rasped to a star topology in the 
ne^ork 40 of Figure 2. .f toe server 42 cannot implement this version of the star 
topology men. as a .est resort, toe server 42 routes toe message through one or 
both of the servers 64s and 64r. 

Next, referring to step 76. if a PTP topology is possible, then the server 42 
sends the IP address and toe dynamic encryption key of the" receiving device 
specified by toe routing preferences (or of the computer 12r if R is running toe 
receiving device) to the sending device. 

Then, referring to step 77, the sending device sends toe message directly to 
the recerving device-thus bypassing toe server 42, and with respect to toe neLo* 
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60 of Figure 3, bypassing the servers 64s and 64r — and, after it sends the 
message, conventionally closes the direct PTP communication path over which the 
sending device sent the message. 

Alternatively, referring to step 79, if the server 42 cannot implement a PTP 
5 topology, the server 42 implements a star topology. Specifically, the server 42 

opens a communication path between itself and the sending device and notifies the 
receiving device specified by the recipient's routing rules of the incoming data steam 
that forms the message. For example, as discussed above, if the e-mail client 24s is 
the sending device and the desktop pager 20r is the receiving device, then the 
1 0 server 42 opens a path between the e-mail client 24s and itself via the e-mail server 
26s, and notifies the desktop pager 20r that a message is forthcoming. 

Next, referring to step 81 , the sending device transfers the message to the 
server 42. 

Then, referring to step 83, the server 42 reformats the message if necessary 

15 and then sends the message to the specified receiving device. For example, if the e- 
mail client 24s is the sending device and uses a first message format and desktop 
pager 20r is the receiving device and uses a second message format, the server 42 
converts the message from the e-mail client 24s into the second format, and then 
transfers the reformatted message to the desktop pager 20r. 

20 Next, referring to step 85, when the sending device finishes sending the 

message, it notifies the routing server 42, which conventionally closes the 
communication path between itself and the sending device. 

Then, referring to step 87, the server 42 conventionally closes the 
communication path between itself and the receiving device. 

25 Thus, the servers 42 of the networks 40 and 60 of Figures 2 and 3, 

respectively, can facilitate more efficient communication between message-sending 
and message-receiving devices by automatically selecting the best network 
communication topology. Also, the servers 42 allow a recipient to redirect a 
message from one receiving device to another receiving device, and allow a 

30 message device of one type to communicate with a message device of another type. 

Figures 5-8 disclose embodiments of techniques that allow a sender to send 
a message to the recipient such that the server 42 can route the message according 
to the recipient's routing preferences. Figures 5 - 8 are discussed in conjunction 
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with the network 40 of Figure 2, it being understood that the disoussion is aiso 
applicable to the network 60 of Figure 3 unless otherwise noted. 

Figure 5 is a computer screen 90 that allows a sender who is a registered 
user of the routing server 42 to send messages to a recipient who is also a 
5 registered user of me server 42. Using the routing diem 48s. the sender creates one 
or more groups of recipients, and adds the recipient to one of these groups For 
example, a sender may have a group for wo* colleagues and another group for 
parsonai mends. The client 48r for each designated recipient prompts the respective 
rec,p,ent for messaging information, receives the information from the recipient and 
10 makes this information available to me sender via me server 42. Based on tht 

information, me rounng client 48s generates the screen 90 on the sender's computer 

The screen 90 includes a list field 92, which includes a list of messaging 
devrces ma, the recipient has made available to receive messages from the sender 
15 In one embodrment, the routing client 48s is run in a Microsoft Windows* 

Z£T" T* "* sender 030 select *• desired messa9i "s **» b * ««**» 

and wfth a mouse. For exampie, if ma sender points and clicks on the 

Page icon, man the routing client 48s will prompt me sender to enter a message to 
the deskfop pager 20s, which win sand me message to the recipient's desktop pager 

of m d6ViCe SPeCme " by ,he •"-> •»> •» U 

o,me server 42 as discussed above in conjunction with Figure 4 In one 

embodrment, some messaging devices such as me desktop pager 20s and a cha, 

device (abated by dicking on me "Char icon, acua.,y run as par, of the roufing 

5 dt"L r: rOUt "' 9 ° ,ferrt48S 0Pera,eS 3 -"—erforomer message 
5 devces as well. For example, me field 92 allows me sender ,o send messages ,o 

he recpren s e-mai, server 28r, fox, or .efophone. In response to the sender's 

selector, o, ,hese devices, me roufing clien, 48s respectively ac.iva.es the sender's 

mZ TT " ^ <n0 ' Sh ° Wn) " ** «" Se " der «" - — •» 

message to ,he respects receiving devices. Furthermore, afthough icons are 

shown for certain messaging devices, the field 92 may include icons for other 

SUCh " ^ n °' limfted '° 8 WireteSS (•* « a 

personal digital assistant (PDA). 
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Other features of the screen 90 include an image field 98, which can include 
the recipient's photo or a live picture, a greeting field 100, which can include the 
recipient's greeting, and a log-in status field 102, which indicates whether the 
recipient — or more accurately the computer 12r running the client 48r — is logged 
5 onto the server 42. The screen 90 may also include other fields such as a schedule 
field that includes the recipient's current calendar. 

Figures 6 and 7 are web pages that allow a sender who is not registered user 
of the routing server 42 to send messages via the web browser 22s to a recipient 
who is a registered user of the server 42. 

10 Figure 6 is a recipient's home page 104 on the server 42. The sender 

accesses the home page 104 by using his web browser 22s to access the URL for 
the home page 104. Like the screen 90 of Figure 5, the page 104 includes a device 
field 106, a greeting field 108, a log-in status field 110, and an image field 114, and 
may include other fields such as a schedule field. Like the screen 90, although icons 

15 for certain messaging devices are shown, the device field 106 may include icons for 
other messaging devices such as but not limited to a wireless pager (e.g. Skytel* 8 *) or 
a personal digital assistant (PDA). 

The sender uses the web browser 22s to send a message to a receiving 
device selected from the field 106, and as discussed above in conjunction with 

20 Figure 4, the server 42 reformats the message if necessary and routes the message 
to the receiving device specified by the recipient's routing preference. In one 
embodiment, the page 104 also includes an option field 116. The "My Groups" 
option allows the sender to view the groups to which the recipient belongs. The "My 
Profile" option allows the sender to view the recipient's profile, which includes 

25 additional information about the recipient. The "Search My Agent" option allows the 
sender to access the web pages of other registered users of the server 42 without 
knowing their URLs. This option is also available from the general home page (not 
shown) of the server 42. A user, however, may instruct the server 42 to prohibit 
others from accessing his web page through the "Search My Agent" option for 

30 security or privacy reasons. 

Figure 7 is a page 120, when the server 42 sends the web browser 22s if the 
sender clicks on the "My Email" icon on the page 104 of Figure 6. The screen 120 
prompts the sender for information and allows the sender to send an e-mail message 
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to the recipient via the web browser 22s. As discussed above in conjunction with 
Figure 4, the server 42 routes this e-mail message to the recipient's e-rnaii server 
26s or to another of the recipient's message devices according to the recipient's 
routing preferences. 

Figure 8 is a screen 122, which allows a registered user of the server 42 to 
send a message from the user's own web site to a registered or unregistered 
recipient. The screen 122 prompts the sender for the necessary information, such 
as the recipient's user name or e-email address. The screen 122 also includes a 
"Group Options" field, which allows the user to form and join user groups, to invite 
other registered users to join a group, and to unjoin groups. 

Referring to Figures 9 through 1 1 , embodiments of the techniques for setting 
a recpient's routing preferences and routing messages according these routing 
preferences are discussed. 

Figure 9 is a flow chart showing how the server 42 and the receiving client 48r 
route messages according to an embodiment of the invention. The flow chart of 
Figure 9 is similar to the flow chart of Figure 4, except that it focuses on message 
routing instead of on the determination of the network topology. 

Referring to step 130, the server 42 receives the message-initiation leader 
from the sending device. Next, referring to step 132, the server 42 determines 
whether or not the recipient's computer 12r, which runs the client 48r. is logged onto 
the server. If not, the server 42 routes the message according to the recipient's off- 
line routmg preferences. For example, in one embodiment, if the recipient's device 
to which the sender directed the message is unavailable, then referring to step 134 
the server 42 notifies the sender that the intended receiving device is unavailable ' 
The server 42 may give the sender the option of sending the message to the 
receiving device specified by the off-line routing preferences or of canceling the 
message. Next, referring to step 136, if the sender elects to send the message then 
the server 42 routes the message to the receiving device specified by the recipient s 
off-hne routing preferences. For example, suppose that the sender wants to send a 
message from the desktop pager 20s to the desktop pager 20r but the computer 12r 
•s not logged onto the server 42 via the client 48r. Furthermore, suppose that the 
recipient's routing preferences instruct the server 42 to route desktop pages to the e- 
mail server 26r if the computer 12r is off line. Thus, the server 42 informs the sender 



14 



WO 00/41533 



PCT/US00/00688 



that any page he sends will be routed to the recipient's e-mail server 26r and asks 
the sender if he still wants to send the page or if he wants to cancel and wait until 
later. .If the sender decides to go ahead and send the page, the server 42 will route 
the page to the email server 26r. In another embodiment, however, the server 42 
5 routes the message to the preferred off-line device without informing the sender. 

Referring to step 138, if the computer 12r is logged onto the server 42, then 
the server 42 routes the message to the receiving device specified by the recipient's 
online routing preferences. For example, the on-line routing preferences may 
instruct the server 42 to route a page from the desktop pager 20s to the desktop 
10 pager 20r. 

Next, referring to step 140, after the server 42 routes the message, the 
receiving client 48r determines if the specified receiving device has a rerouting 
condition, such as a user-activity rerouting condition, associated with it. If there is no 
condition, then referring to step 142, the server 42 and the client 48r take no further 

15 action with respect to the message. If there is a rerouting condition, however, then 
referring to step 144, the client determines if the condition is met. If the condition is 
met, then referring to step 146, the client causes the server to reroute the message 
to the device specified by the routing preferences. For example, as discussed below 
in conjunction with Figure 11, the routing preferences may specify that if a recipient 

20 does not "pick up" a message to the desktop pager 20r within a certain amount of 
time, then the client 48r is to cause the server 42 to reroute the message to another 
receiving device such as the e-mail server 26r. Thus, if the recipient does not pick 
up the page within the allotted time, then the client 48r causes the server 42 to 
reroute the page to the e-mail server 26r. Referring again to steps 144 and 146, in 

25 one embodiment, the client 48r monitors the receiving device to determine if the 

condition is met. This embodiment is useful when the receiving device, for example 
the desktop pager 20r, is part of the client 48r. In another embodiment, the receiving 
device notifies the client when the condition has been met. . 

Figure 10 is a screen 147, which is generated by the routing client 48r and 

30 which prompts a recipient to enter his off-line routing preferences. Specifically, a 
prompt 148 prompts the recipient to select the preferred device or devices for 
receiving a message intended for the desktop pager 20r if the computer 12r is not 
logged onto the server 42 when the message is sent. In the embodiment shown, the 
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14* Thus rfthe reo,p,ent is out of town and is not inning his computer 12r then 
the server 42 win forward all desktop pages to his e-mail server 26,1 
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prcwded any date „ me oomputer 12r within the time period specified in me box 
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embodiment, these available message devices are included in the device fields 92 
and 106 as discussed above in conjunction with Figures 5 and 6, respectively. More 
specifically, on its first boot, the client 48r includes all such devices in the fields 92 
and 106. The recipient, however, can remove one or more of these devices from the 
5 fields 92 and 106. On subsequent boots, the client 48r will omit from the fields 92 
and 106 any message devices previously removed therefrom, unless the recipient 
subsequently adds these devices back to the fields 92 and 106. 

Next, referring to the step 166, the booted client 48 sends to the server 42 the 
identifies, addresses, and other information for the message devices that are listed in 

10 the fields 92 and 106, and also sends the server 42 the recipient's routing 
preferences as discussed above. 

Therefore, the recipient does not have to perform a tedious installation of the 
message devices into the client 48r or the server 42. Furthermore, the client 48r 
may even identify and list message devices that the recipient didn't even know were 

15 installed on the computer 12r! 

Figure 13 is a display screen 170, which one embodiment of the client 48r 
generates according to the flow chart of Figure 12 to allow a recipient to remove and 
add message devices that are available to senders. The available devices are listed 
in a field 172, and can be deleted or added by clicking on the "Delete Device" and 

20 "Add Device" icons, respectively. When the "Add Device" icon is selected, the client 
48r lists for the recipient's selection all message devices installed on the computer 
12r but not currently available to senders, i.e., not listed in the fields 92 or 106. 

Figure 14 is a flow chart of a callback procedure executed by the server 42 
and the routing client 48s according to an embodiment of the invention; 

25 Referring to step 180, the server 42 maintains a list of the users that are 

currently logged onto the server 42 via their respective clients 48, and also maintains 
a list of undelivered callback requests. 

Next, referring to steps 182, 184 and 186 ? in one embodiment, the.server 42 
provides to a sender the log-on status of the recipients in the sender's groups, such 

30 as provided in the field 102 of the screen 90 in Figure 5. More specifically, referring 
to step 182, the sender logs onto the server 42 via the computer 12s and the client 
48s. Next, referring to step 184, the server 42 determines the log-on status of each 
user in the sender's groups by checking the logged-on list. In one embodiment, the 
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server 42 stores the membership date for the sender's groups so that the client 48s 

nee no send this data.to tee se „ « me the sender |ogs ^ ^ ^ 

Then . re femng ,o step 186, me server 42 sends the log-on status of each 

users to the sending client 48s. .n one embodiment the sending client 48s 2 aL 

~:;r n s,a,us of a - - - - — - <* r 

Next, referring to step 188, the sender requests a caflback. That is the 
sender .quests me setver 42 „ ^ , ^ . «- 

recrprent The ca„back request notifies the recipient ma, me sender wishe Mo 
10 contact him/her. For exampto, in one embodiment, refemng to the It L 

SET ' ^ ^ ™ 8 — * — - - Set A 

and d J 116 "' referring ,0 ^ 1K ' * e SSrVer42 ^ 'ne logged-on lis, 

anddetarmmes whether the recipient is togged onto theserver 

delivers the callback request to the recipient's client 48r 

adds thtir? 9 10 SfeP 196 ' i " he reCiPien ' " n °' ,099ed ° n ' *» *• serve, 

Si «r: : r uest ,o - °—* "*•*» * ^ 1 «. — - 

0 hasT T Se ' Ver42 Ch6CkS ' he Ca " back " s,to dete «"™ »*• recipient 

0 has anv outstanding caflback requesta. „, as in mis example, the .cipien, doe 

eZrr"'" 9 r6qUeSt *" - — « "Avers me Lllbal 

request to the recipient's client 48r. 

Thus, the callback procedure eliminates the probiems associated wite 
convenhona, polling as discussed above in conjunct with Figure 1 

Referring to Figure 15, in one embodiment of the callback procedure 
descnbed ,n tee flow chad of Figure 14. tee cflen. 48r generates a screen 200 in 
-sponse to the caflback reques, delivered b y tee server 42. The screen 200 

ZZ2 . * • *" reeiPten * h3S *" ° pti0n ° f •» «rver 42 to 

noflfy the sender tea. tee recipton, » now available or of preventing tee server 42 

IZ o?: te^ 6 ^ ^ — * ^equesf if he/sfre does no, 
want to be bothered by the sender. 
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Figure 16 is a flow chart of a message-routing learning procedure 
implemented by one embodiment of the routing client 48r. Implementing this 
procedure allows the client 48r to automatically suggest, generate, or maintain the 
recipients routing preferences. 
5 Referring to step 201 1 the client 48r periodically or continually monitors the 

recipients actions with respect to his received messages. Next, referring to step 
202, the client 48r automatically suggests changes to, sets, or updates the routing 
preferences based on patterns that the client 48r has detected with respect to the 
received messages and the recipient's related actions. Then, referring to step 204, 

10 the client 48r sends these new routing preferences to the server 42 (with the 

recipients permission if the client 48r has only suggested new routing preferences). 

Still referring to steps 201 , 202, and 204, in one embodiment, the client 48r 
implements a statistical correlation matrix, such as a conventional Baysian network, 
to correlate message characteristics (e.g., sender's identity, time of day message 

15 received) with the recipients actions (e.g., forward or ignore message) for a group of 
messages such as the last one thousand received messages. 

For example, suppose that using this technique, the client 48r determines that 
out of fifty phone calls to the recipients work phone on weekends and after 5:00 p.m. 
on weekdays, the recipient has answered two, and the rest have been routed to the 

20 recipients voicemail server 30r. (In one embodiment, the client 48r can determine 
whether a call is answered or sent to voice mail by communicating with the voicemail 
server 30r using conventional techniques.) Therefore, in response to this pattern, 
the client 48r may suggest that the recipient adopt a routing preference that causes 
the server 42 to route all work phone calls received on weekends and after 5:00 p.m. 

25 and on weekdays directly to the voicemail server 30r, and thus reduce the chances 
that the caller will be aggravated by the phone ringing a number of times before he is 
transferred to voicemail. 

Or, suppose that the client 48r determines that, out of twenty five e-mail 
messages from a particular sender when the e-mail client 24r also displays unread 

30 e-mail messages from other senders, the recipient has opened this particular 

sender's messages first twenty four times. (In one embodiment, the client 48r can 
determine the order in which unread e-mail messages are opened by communicating 
with the e-mail client 24r or e-mail server 26r using conventional techniques.) In 
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More specifically, referring to step 220, the "new" client 48s logs onto the 
server 42 via the computer 12s and determines whether or not the client 48r is 
logged onto the server 42. The new client 48s may make this determination in a 
variety of ways. In one embodiment, the server 42 automatically provides the new 
5 client 48s with the log-in status of the client 48r in a manner similar to that discussed 
above in conjunction with Figure 14. In another embodiment, the new client 48s 
requests the log-in status of the client 48r from the server 42 also in a manner similar 
to that discussed above in conjunction with Figure 14. 

Next, referring to step 222, if the client 48r is not logged onto the server 42, 

10 then, referring to step 224, the new client 48s transfers its message-routing 

preferences to the server 42, and referring to step 226, the server 42 proceeds to 
route messages according to these routing preferences as discussed above in 
conjunction with Figure 4. 

On the other hand, if the client 48r is logged onto the server, then the client 

15 48s instructs the client 48r to become passive. The client 48s may provide these 

instructions to the client 48r in a number of ways. In one embodiment, the new client 
48s requests the server 42 to set up a PTP communication path between it and the 
client 48r as discussed above in conjunction with Figure 4. In other embodiments, 
the new client 48r requests a communication path to the client 48r through the server 

20 42 (star topology) also as discussed above in conjunction with Figure 4, or the server 
42 instructs the client 48r to become passive. 

Referring again to steps 224 and 226, after the client 48r is instructed to 
become passive, then the new client 48s transfers its routing preferences to the 
server 42, which routes messages according to these preferences. 

25 The flow chart of Figure 1 9 shows an embodiment of a procedure to select a 

new primary client among multiple clients that are all already logged onto the server 
42. 

Referring to step 230, multiple clients 48 are logged onto the server 42, and 
one of these clients is the primary client and the others are passive clients. For 
30 example purposes, suppose that the user went home from work and left his work 
client 48s running. Then suppose he logs the home client 48r onto the server 42, 
and according to the procedure described in conjunction with Figure 18, the client 
48r becomes the primary client and the client 48s becomes the passive client. 
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Referring to step 232 and using the above example, the passive client 48s 
detects a condition, such as user activity, that indicates H should now be the primary 
clrent. For example, this situation occurs if the user goes back to work without 
egging off me client 48r and starts using the computer 12s. The theory here is mat 
the user wants the client on the computer he is using, here the client 48s, to be the 
pnmary client so that his messages are routed accordingly, m one embodiment the 
chant 48s detects the user activity by monitoring the input device 13s as discussed 
above in conjunction with Figure 9. 

Next, referring to step 234, the passive client 48s instruct the pnmary client 

21 b T, e .T 8iVe - ^ embodim ^ ■» Pa*™ client 48s communicates 
w,th the cl,ent48r as discussed above in conjunction with Figure 18 

Then, referring to the step 236, the passive client 48s transfers its message 
routng preferences and other information to the server 42 and becomes the new 
primary client. 

Referring to step 238, the server 42 then routes subsequent incoming 
messages according to the routing preferences provided by the new primary client 

From the foregoing it will be appreciated that, although specific embodiments 
of the mvention have bean described herein for purposes of illustration, various 
mediations may be made without deviating torn the spirit and scope of the 
invention. 
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What is claimed: 

1 . A server for facilitating communication between a sending device and a 
receiving device, the server comprising: 

a storage device operable to store a program; and 

a processor coupled to the storage device, operable to execute the program, 
and having first and second states, the processor operable to allow the sending 
device to send a message past the processor to the receiving device if the processor 
is in the first state, the processor operable to receive the message from the sending 
device and to send the message to the receiving device if the processor is in the 
second state. 

2. The server of claim 1 wherein the processor is operable to receive a 
message-initiation header from the sending device and to enter one of the first and 
second states in response to the message-initiation header. 

3. The server of claim 1 wherein the processor enters the second state 
only if the sending device cannot send the message directly to the receiving client. 

4. The server of claim 1 wherein the processor is operable to receive a 
message routing preference of a user of the receiving device and to enter one of the 
first and second states in response to the message routing preference. 

5. A server for allowing communication between a sending device of a 
first type and a receiving device of a second type, the server comprising: 

a storage device operable to store a program; and 
a processor coupled to the storage device and operable to execute the 
program, receive a message routing preference of a user of the receiving device, 
and to route a message from the sending device to the receiving device in response 
to the message routing preference. 
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maM "Pon occurrence of a condition specified by the 

message routing preference. 

9. The server of claim 5 wherein the processor is operable to receive the 

ZZ£1? sendin9 device ' *° ~ ,he -—»• - • *™ ™ 

10. The server of claim 5 wherein the processor is operable to route the 
message ,o ttie receMng device upon me occurrence of a colon spe^ b^the 
message routing preference. M"iieoDytne 

11 ■ The server of claim 5 wherein the processor is operable to first allow 

ZTZT* t0 send messa9e 10 a ~ 9 *-* - -S.tr 

specmea by the message routing preference. 

a userlL ASe,Ver,0ra ' lowir * communica«on between a firs, receiving device of 
a user and a sending device, the server comprising: 

a storage device operable to store a program; and 

operab^r 880 ' COUP ' ed '° S ' 0ra9e ^ 0perabte to ^ure the program 
operable ,o receive a message routing preference of the user, and, in response to 
•he message routing preference, operable ,o route ,o me flrs, receiving deZ a 
message tha, the sending devfce directed ,o a second receiving devi» c Z US er 
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13. The server of claim 12 wherein the processor is operable to route the 
message to the first receiving device upon occurrence of a condition specified by the 
message routing preference. 

14. The server of claim 12 wherein: 

the second receiving device comprises a desktop pager of the user; and 
the processor is operable, in response to the message routing preference, to 

route the message to the first receiving device if no computer logged onto the server 

is running the user's desktop pager. 

15. The server of claim 12 wherein: 

the message is sent by the sending device in a form that is compatible with 
the second receiving device; and 

the processor is operable to receive the message from the sending device, to 
convert the message into a form that is compatible with the first receiving device; 
and to send the converted message to the first receiving device. 

16. The server of claim 12 wherein: 

the second device comprises a desktop pager; and 

the processor is operable to route the message to the first receiving device 
after a period of user inactivity on a computer that is running the desktop pager, the 
message routing preference specifying the duration of the period. 

17. The server of claim 12 wherein: 

the second device comprises a desktop pager; and 

the processor is operable to allow the sending device to send the message to 
the desktop pager, to retrieve the message from the desktop pager, and route the 
message to the first receiving device after a period of user inactivity on a computer 
that is running the desktop pager, the message routing preference specifying the 
duration of the period. 

18. A server for communicating with a client, the server comprising: 
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a first storage device operable to store a program; and 
a processor coupled to the storage device and operable to execute the 
program and to store a log-on status of the client. 

19. The server of claim 18 wherein the processor is operable to store the 
log-on status in the first storage device. 

20. The server of claim 1 8 wherein: 
the processor comprises a memory; and 

the processor is operable to store the log-on status in the memory. 

21. The server of claim 1 8, further comprising: 
a second storage device; and 

wherein the processor is operable to store the log-on status in the second 
storage device. 

22. The server of claim 18, further comprising: 
a log-on-status storage device; 

wherein the processor is operable to, further comprising: 
maintain a record of logged-on clients in the a log-on-status storage device; 

and 

wherein the processor is operable to store a value in the record while the 
client is logged onto the server, the value identifying the client. 

23. A server for first and second clients, the server comprising: 
a storage device operable to store a program; and 

a processor coupled to the storage device and operable to execute the 
program, to receive a callback request from the first client, and to provide the 
callback request to the second client. 

24. The server of claim 23, further comprising: 
a callback status memory; 
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wherein the processor is operable to maintain a record of callback requests in 
the callback status memory, provide the callback request to the second client if the 
second client is logged onto the server, store the callback request in the record if the 
second client is logged off of the server, and provide the stored callback request to 
the second client if the second client subsequently logs onto the server. 

25. The server of claim 23 wherein the processor is operable to receive a 
cancellation of the callback request from the second client. 

26. The server of claim 23, further comprising: 
a log-on status memory; 

a callback status memory; and 

wherein the processor is operable to store the identities of the first and 
second clients in the log-on status memory if the first and second clients, 
respectively, are logged onto the server, to obtain the log-on status of the second 
client from the log-on status memory in response to receiving the callback request 
from the first client, to provide the callback request to the second client if the second 
client is logged onto the server, and to store the callback request in the callback 
status memory if the second client is logged off of the server first . 

27. A method for facilitating communication between a sending device and 
a receiving device, the method comprising: 

allowing a message from the sending device to be directly routed past a 
server to the receiving device if the server is in first state; and 

receiving the message from the sending device with the server and sending 
the received message from the server to the receiving device if the server is in the 
second state. 

28. The method of claim 27, further comprising setting the state of the 
server in response to a message-initiation request from the sending device. 
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29 The method of claim 27. further comprising setting the server in the 
second state on, y if the sending device cannot send the message directly to he 
receiving device. «»wiyioine 

S8 rv e r 3<> ' ^ " **" ^ Settin 9 •» — of the 

server ,n response to a message routing preference of a user. 
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preference of a user of the receiving device. 

32. The method of claim 31 , further comprising- 
com™" 9 ^ ""— ""*» P — «* « — «— on a 
.ooo^T!! 9 mSSSa9e roU " n9 PreferenCe to 8 Se ™ me computer is 

mesJe 3 to ^ ^ " ^ " ™~ the 

message ,o me receding device upon occurrence of a condttion specified by the 
message routing preference. y 

messaoTto ml" 6 ^ " **" " Wherei " "» COm ^ s •«*« me 

message to me receding device when no client of the user is logged onto a server 

the. ,s ,n communicafion wim ,he sending and receiving devices 

35. The method of claim 31 wherein the directing comprises- 

^ convert me message into a form that is compatible with the receiving device; 

sending the converted message to the receiving device. 

36. The method of claim 31 . further comprising: 
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allowing the sending device to send the message to a receiving device of the 
first type; and 

wherein the directing comprises directing the message to the receiving device 
after the allowing and upon the occurrence of a condition specified by the message 
routing preference. 

37. A method, comprising routing a message from a sending device to a 
first receiving device of a user in response to a message routing preference of the 
user, the sending device having directed the message to a second receiving device 
of the user. 

38. The method of claim 37 wherein the routing comprises routing the 
message to the first receiving device upon occurrence of a condition specified by the 
message routing preference. 

39. The method of claim 37 wherein: 

the second receiving device comprises a desktop pager; and 

the routing comprises routing the message to the first receiving device if no 

computer running the desktop pager is logged onto a server that is in communication 

with the sending and first receiving devices. 

40. The method of claim 37 wherein: 

the message is sent from the sending device in a form that is compatible with 
the second receiving device; and 

the routing comprises converting the message into a form that is compatible 
with the first receiving device and sending the converted message to the first 
receiving device. 



41 . The method of claim 37 wherein: 

the second device comprises a desktop pager; 

the message routing preference specifies a period of user inactivity on a 
computer that is running the desktop pager; and 
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the routing comprises routing the message to the first receiving device after 
the period has elapsed. 

th * k 4 t " A m6th0d ' C ° mprising St ° rin 9 on a **™ a log-on status for a client 
that has log-on privileges with respect to the server. 



43. The method of claim 42 wherein the storing comprises storing a value 
to 1721 ' 0CatiOn " ^ C ' lent " ,0 " ed ° nt ° ^ SerVer ' thS — —ponding 



44. A method, comprising 

and 



receiving a callback request from a first client that is logged onto the server; 



providing the callback request to a second client. 

45. The method of claim 44, further comprising: 
maintaining a record of callback requests; 

providing the callback request to the second client if the second client is 
logged onto the server; and 

the servlr 9 ^ * *" ^ ^ S6COnd C ' ient is lo ^ ed off ° f 

46. The method of claim 44, further comprising: 

receiving a callback cancellation request from the second client- and 
canceling the callback request in response to the cancellation request. 

47. The method of claim 44, further comprising: 

receiving a callback acknowledgement from the second client- and 
notifying the first client that the second client is available. 

48. The method of claim 44, further comprising: 
maintaining a record of callback requests; 
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providing the callback request to the second client if the second client is 
logged onto the server; 

storing the callback request in the record if the second client is logged off of 
the server; and 

providing the stored callback request to the second client if the second client 
subsequently logs onto the server. 
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